Configura acesso e cotas por consumidor na API de uso - #156

O que esse PR faz?

Configura os modos public e key_required nas rotas existentes. Valida chaves fornecidas e aplica cotas compartilhadas no Redis: 30 consultas anônimas ou 300 por chave a cada 60 segundos, configuráveis. Excesso retorna 429/1020 com Retry-After; falha do Redis retorna 503/1000.

Onde a revisão poderia começar?

counter_api/access.py, seguido de counter_api/rate_limit.py. Sete commits separam configuração, contador, acesso, cotas, relatórios, OpenAPI e documentação.

Como este poderia ser testado manualmente?

1. Com Redis configurado, consultar /r51/platforms sem chave em modo public; repetir com chave válida e inválida (401).
2. Usar key_required: sem chave deve retornar 401; com chave válida, 200. /r51/status permanece público.
3. Reduzir as cotas no ambiente de teste e conferir 429/Retry-After; indisponibilizar o Redis de teste e conferir 503 nas rotas de dados.
4. Conferir relatórios e arquivos, schema dos dois modos e login administrativo.

Validação automatizada em Docker isolado: 364 testes passaram, 2 ignorados; inclui Redis real. Black, isort, flake8, OpenAPI nos dois modos e Gitleaks aprovados.

Algum cenário de contexto que queira dar?

Permite diferenciar consultas anônimas de integrações identificadas, como o backend do OCABr, sem duplicar rotas ou alterar métricas. Períodos incompletos, release e implantação não fazem parte deste PR. Acesso anônimo diverge do requisito de autenticação COUNTER; não se declara certificação.

Screenshots

Não se aplica: alteração de API.

Quais são os tickets relevantes?

Closes #155.

Referências

• COUNTER R5.1.1 — autenticação e segurança
• COUNTER — erros e exceções

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — processa chaves de API e IPs para controle de acesso/cotas. Os identificadores dos contadores são hashes SHA-256, sem credenciais em texto; hash de IP não constitui anonimização. Chaves devem ficar no backend, trafegar por HTTPS e ser omitidas de logs.
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — centraliza acesso público ou por chave, rejeita chaves inválidas e aplica cotas. Status permanece público e administração exige login.
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique):

Pendente: SonarQube/Trivy não foram executados nesta validação local. Gitleaks aprovado nos sete commits; não substitui o pipeline de segurança.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não — mantém os endpoints existentes, mas altera sua política de acesso. HTTPS e configuração de proxy/Redis devem ser verificados antes da implantação; este PR não publica o serviço.

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)